Subject: Alternate DLSw transports

From: "jim (j.) cobban" <[email-masked]>
Date: Mon, 29 Apr 1996 11:21:00 -0400

The following is my previous paper on alternate DLSw transports, as updated
to expand in particular on the Frame-Relay application.

If DLSw is to use an alternate transport layer there are several issues to
identify.

Reliability
-----------
DLSw assumes that the transport layer provides reliable, ordered, delivery of
protocol data units.  This imposes some constraints upon the sorts of
transport implementations which can be used.  In particular a best-efforts
transport, such as UDP/IP, or TP0/CLNP, or UI frames over LANs, or raw
Frame-Relay, SMDS, or ATM, is unsuitable.  However X.25 and TP4/CLNP and
TP0/CONS are suitable.

For the best efforts transports and data link layer implementations it is
necessary to add an additional protocol layer to provide end-to-end error
recovery.  There are a number of possibilities.

  1) TCP.  However the protocol layer separation between TCP and IP below it
     is not clean.  This has, in particular, caused a lot of the problems in
     implementing IPng.  It is therefore not practical to use TCP over any
     other lower layer.
  2) HPR/RTP.  There are two concerns which prevent the use of RTP.  Firstly
     the protocol would need to be licensed, since RTP is only currently
     licensed for use in APPN/HPR implementations.  Secondly the protocol is
     optimized for use in networks in which the underlying layer delivers all
     packets over the same route through the network, therefore guaranteeing
     minimal variation in delay.  RTP is extremely sensitive to variation in
     delay compared to other transport protocols.
  3) Asynchronous Balanced Mode (LLC2, LAPF multiple acknowledgement subset).
     The big advantage of this protocol is that it is very light
     weight.  Another advantage is that almost every platform already has
     an implementation of it.  The largest concern is that LLC2 assumes low
     variation in delay, although existing implementations are not as
     sensitive as RTP.

In the following I examine the characteristics of using an ABM protocol
stack to provide end to end error recovery and flow contol in more detail.

Most data link implementations explicitly support the use of an ABM protocol
in their data link layer, by replacing the normal UI with I and S frame
control codes.  This is explicitly supported by all IEEE 802 LAN media, by
Frame-Relay, and by SMDS.  It is not supported by DIX Ethernet, however IEEE
802.3 and DIX Ethernet frames may be intersperes on the same media.  In this
mode ABM adds only ONE byte to each data frame, although in some
circumstances, in particular if most of the data is flowing in only one
direction, additional supervisory frames may be required.

However using ABM at this level may cause some implementation difficulties.
For example in Frame-Relay, using RFC1490 multi-protocol encapsulation, it
forces the LAPF ABM frames to be decoded before the encapsulated protocol is
identified.  This may be inappropriate, even though it is explicitly
permitted by RFC1490, and indeed is the architecturally preferred
implementation for the transport of X.25 over Frame-Relay.  An additional
motivation may be that most early frame-Relay DTE implementations did not
implement the multiple acknowledgement subset of LAPF since it is only
mandated for support of SVCs on Q.933.  Therefore it is common for protocols
to use RFC1490 only to identify that an ABM protocol is used
as a subsequent protocol layer.  Specific examples are the Annex G
encapsulation of X.25, in which LAPB is encapsulated inside Frame-Relay, and
the SNA BNN encapsulation in which LLC2 is used on top of Frame-Relay.
However even in this case LLC2 only adds 3 bytes to the frame overhead, which
is much less than other reliable transports.

The primary concern with the use of an ABM protocol, such as LLC2, as an
end-to-end transport, is that ABM was designed for operation over media,
whether serial links or LANs, which provide relatively low, and relatively
consistent delay by comparison with packet networks such as the Internet.
ABM has low overhead because it can use fixed time-outs, and fixed transmission
windows, taking advantage of the delay characteristics of the underlying
media.  An ABM based transport is only viable if we can be assured that the
delay characteristics of the public media, whether Frame-Relay, SMDS, or ATM,
are suitable.  It is my contention that they are, for reasons discussed in
the following paragraphs.

The first, and easiest to understand, reason that public data network delays
are tolerable is that the backbone links of all public networks are becoming
faster at an extraordinary rate.  10 years ago the backbone links of most
public data networks were 56Kb/s.  That meant that at each hop a 1K byte
packet would experience a MINIMUM 1/7th of a second delay.  Any congestion at
all could quickly increase that to the point where the end to end delay could
vary wildly up to several seconds.  Today the backbone links of most networks
are T3, and the engineered utilization levels are much lower.

The second factor is that with the increase in traffic, and the reduction in
tariffs for high speed links, the public networks are becoming more highly
meshed.  This reduces the number of trunks which a packet must queue for as
it crosses the network.

The third factor has to do with the way that public networks are implemented.
Unlike the Internet, the public data networks are connection oriented.  When
a connection is established a route is chosen for it across the network, and
bandwidth is reserved where required.  Normally all of the packets of a
connection follow the same route across the network, and therefore have the
same delay.  Routes change only when the topology of the network changes.  If
this sounds familiar, it is because it is philosophically similar to
APPN/HPR.  Further at each hop a maximum queue size is typically maintained
for a particular class of service.  When the congestion level on a trunk
reaches the level where that queue size is reached, subsequent packets are
discarded.  This creates the situation where the public network can guarantee
that either a packet will be delivered within a particular upper bound on
delay, or it will not be delivered at all.

The first two factors above guarantee that the normal end-to-end delay across
a public data network is quite low.  The last factor guarantees that the
end-to-end delay is bounded for all packets which are actually delivered.
These are conditions which ABM, with its fixed timers, is well suited to
exploit.  If an ABM implementation is tuned so that its T1 timer is equal to
the maximum round-trip delay for which the public network can guarantee
delivery, then the ABM implementation will only retransmit an I frame in the
case where the network has discarded the original.  The delivery of duplicate
I frames is minimized.

The question of the use of LLC2 as a transport layer is being discussed in
the ISO under the topics Transport Layer Fast Byte (DIS 14699) and Network
Layer Fast Byte (DIS 14700).  The concept which is espoused in these
standards is that there are many implementations in which a reliable data
link layer is imbedded in the hardware, and therefore runs faster than any
software implementation at a higher layer.  There are also applications in
which the functions provided by the network and transport layers, such as
multiplexing and segmentation, are unnecessary.  These draft specifications
describe how the transport service semantics are mapped directly to network
service semantics in a null transport layer, and how the network service
semantics are mapped to data link service semantics in a null network layer.

Protocol Identification
-----------------------
How is DLSw transport traffic distinguished from other traffic on the same
shared medium?  This must bear in mind the protocol identification
capabilities provided by the various data link implementations.

- on X.25 we could agree on a protocol identifier to use in the first
  byte of the call user data.  This is a rather crowded address space so
  a better option would be to use X'80' as the protocol id, and then use
  the IEEE Subnetwork Access Protocol (SNAP) for protocol identification
  within the call user data.  Related closely to this is using protocol id
  X'00' which signals the use of SNAP headers in each contained data packet
  to permit sharing a single virtual circuit among multiple protocols.
  These options are discussed in RFC 1356.  If a SNAP encapsulation is
  preferred then the AIW should obtain, if it does not already have, an
  Organizational Unique Identifier (OUI) within which to assign a
  protocol identifier.

- on LLC2 there is only the service access point (SAP) index available
  for protocol identification.  This is an extremely crowded address
  space and there is no formal mechanism for reserving individual SAPs
  for use by particular protocols except those recognized by the IEEE
  and ISO.  One option therefore is to specify a default SAP for DLSw
  transport and require that it be overrideable by provisioning.
  Perhaps a better alternative is to use the reserved SAP for SNAP
  protocol identification X'AA'.  Then the same protocol identification
  as was suggested for X.25 could be used.  The only awkwardness with
  this is that I do not believe that SNAP identification has ever been
  used for a protocol which expects reliability from the lower layer.
  For example SNA uses a SNAP identifier on Ethernet, but this SNAP
  identifier indicates that LLC2 is imbedded in the PDU.  This suggests two
  different protocol identifiers, one which indicates that reliability is
  expected from the lower layer, and one which provides it itself by
  including an LLC2 header in the PDU.

- on Ethernet, where LLC2 is not normally available, a SNAP encapsulation
  makes sense, except that the protocol identifiier which indicates that
  the PDU includes LLC2 is required.

- on Frame-Relay using RFC 1490 encapsulation it seems reasonable to
  use the same Q.933 (NLPID X'08') encapsulation used by the other
  protocols (SNA and NetBIOS) which depend upon a reliable data link
  layer.  If this is done the AIW could register another
  layer 3 protocol identifier, say X'7086', as identifying the DLSw
  transport layer.  Another alternative is to use the SNAP protocol
  identification (NLPID = X'80') however as with LANs this has never
  been used with the multiple acknowledgement subset of LAPF (equivalent
  to LLC2), although the RFC1490 formats do reserve space for expanding
  the control field to the two bytes required for I and S frames.  The
  same encapsulation should be used over ATM (RFC 1483).  Cisco may
  suggest some alternatives based upon their practical experience.

- on serial links PPP would appear to be the protocol of choice for
  multiprotocol identification.  There are already several protocols
  which require reliable data link layers which have PPP protocol
  identifiers for example NetBIOS (X'003F'), SNA over LLC2 (X'004B') and
  SNA (X'004D').  It is normally required that if an individual protocol
  requires reliable transmission over PPP that that reliability be
  ensured by the individual transport protocol.  PPP provides reliable
  transmission only for the purpose of ensuring the integrity
  of compression dictionaries.  Therefore it is proposed that the AIW
  register PPP protocol identifiers for DLSw over LLC2 and the
  associated control protocol.

In summary, the conclusion that I come to is that on all media, except
serial links using PPP, the use of LLC2 as a transport by DLSw should be
identified by means of SNAP protocol identification.  The AIW should
have an OUI and assign two protocol ids under this: DLSw assuming that
the base DLC provides a reliable data link layer, and DLSw with LLC2 to
recover from an underlying data link which does not provide reliability.

Discovery
---------
If LLC2 is used on a broadcast medium it makes sense to have a mechanism to
discover the peers on the same medium.  There are a number of effective
techniques which have been used for this.  One option is to register a
multicast address for DLSw discovery.  The format and registry for such a
multicast address will be media dependent.  When a new DLSw joins a shared
medium it would send a frame (UI makes sense to me) to the multicast address.
This frame would be received by the existing peers, each of which would
respond, if appropriately configured, by establishing a transport connection
back to the new peer.  In order to ensure complete connectivity is possible a
new subvector on the capabilities exchange would be used to carry a list
of all MAC addresses of stations on the shared medium that the
initiating station is aware of.  This would deal with the possibility of
the UI not being received by all of the peers.  If sending this
discovery frame did not initiate any responses then the new DLSw would
retransmit it after a time-out.  This could be quite long because the
most probable reason for no response is that this switch is the very
first to join this shared medium.  In that case it will be notified as
soon as any other peer joins.

References:
-----------

 [1] RFC 1042 "Standard for the transmission of IP datagrams over IEEE 802
     networks"

 [2] RFC 1356 "Multiprotocol Interconnect on X.25 and ISDN in the Packet
     Mode"

 [3] RFC 1483 "Multiprotocol Encapsulation over ATM Adaptation Layer 5"

 [4] RFC 1490 "Multiprotocol Interconnect over Frame Relay"

 [5] RFC 1661 "The Point-to-Point Protocol (PPP)"

 [6] RFC 1700 "ASSIGNED NUMBERS"

 [7] DIS 14699 "Transport Layer Fast Byte"
 
 [8] DIS 14700 "Network Layer Fast Byte"
 
 [9] Q.922 Data Link Layer of the ISDN Frame-Mode Bearer Service

 [10] Q.933 Signalling Layer of the ISDN Frame-Mode Bearer Service